Dokumentace k programu na bakalářskou zkoušku z informačních technologií
Autor:
Martin Šlouf
Zátiší 1024
Kralupy nad Vltavou
Tento dokument najdete na Internetu na adrese:
http://sorry.vse.cz/~xslom03/
bak_it/doc/bak_it.html
Implementaci úlohy (prototyp) najdete na adrese:
http://sorry.vse.cz/~xslom03/
bak_it/src/uvod.html
Zdrojové soubory (včetně této dokumentace a dalších souborů) jsou k dispozici v archivu na:
http://sorry.vse.cz/~xslom03/
bak_it/zzz/bak_it.tgz
Zpracováno dne: 18. června 2000
Tento dokument vznikl jako součást programu k bakalářské zkoušce ze základů informačních technologií. Je kompletní dokumentací tohoto programu.
Dokument je rozdělen do několika celků:
Pro popis systému užívám objektových metodik a technologií tak, jak jsou vyučovány na kursech it_357 (Objektově orientované metodiky a technologie = OOMT - analýza) a it_459 (OOMT - design).
Popisovanou firmou je smyšlená cestovní kancelář Cesta s.r.o. Popisovaný informační systém je jakousi evidencí zákazníků, zájezdů a instruktorů.
Značka Význam A_ aktor (Actor) U_ typ jednání (Use case) C_ třída aplikační logiky (Class) TAB_ tabulka v databázi (TABle) db databáze
V této části popíši realitu, ze které systém vychází (slovní popis + kontextový DFD diagram) a požadavky uživatelů na systém (modelj jednání).
Cetsovní kancelář Cesta je menší cestovní kancelář v Praze. Tvoří ji 5 zákaznických center, z nichž jedno je současně sídlem firmy.
Svým zákazníkům zprostředkovává zejména dobrodružněji laděné cesty za poznáním na kole, pěšky či po vodě.
Firmu vede jediný člověk - šéf. Ten má k dispozici sekretářku, která ho může v různých činnostech zastupovat. V každé pobočce sedí 2 lidé ve funkci obchodní referent; ti přicházejí do styku se zákazníky. Jeden z nich je vždy vedoucím pobočky - to sebou nese větší odpovědnost, nikoli však již plat. Firma dále zaměstnává v místě sídla účetního a administrátorku současného IS (správa databáze a internetových stránek). Občas je třeba kontaktovat externího právního poradce. Dalšími zaměstnanci firmy, kteří ovšem vůbec do styku s IS nepřijdou jsou instruktoři zájezdů, pracujících víceméně na plný úvazek. Sečteno a podtrženo: úzké vedení (2 lidé) - "obslužný personál" (14 lidí + externí právník) - cca 30 stálých instruktorů.
Ve firmě probíhá sousta činností, zaměřím se jen na ty, které nějak souvisí se zaváděným IS.
Zcela v kompetenci vedení firmy. Rozhodování o zavedení nových zájezdů probíhá po určité diskuzi uvnitř firmy. Pro každý rok se tvoří nová nabídka (do jisté míry kopírující předloňskou) - údaje o minulých zájezdech si přeje mít vedení stále v evidenci. Starší zájezdy tedy zůstavájí v evidenci (včetně toho, kdo je vedl, kdo si kupoval místa), avšak již nejsou dále nabízeny. Problémem je neplánované rušení zájezdů (přírodní katastrofa, politická situace). U takových zájezdů, pokud jsou zrušeny, je nutno zajistit vrácení peněz.
Vedení najímá takové instruktory, kteří budou schopni vést určitý typ zájezdů. O tom, který konkrétní zájezd potom povedou, rozhoduje vedení po diskuzi s instruktory.
V současné době probíhá jen v pobočkách firmy a pasivně na internetu (nabídka zájezdů). Firma by ráda přenesla komunikaci na Internet (v tom má pomoci i nový systém). Přání zákazníků, na která musí systém reagovat je rezervace místa a zrušení této rezervace. Jak zákazník za místo platí? Není požadována platba v hotovsti na místě. Zákazník může místo rezervovat a do pěti dnů ho zaplatit platbou na účet firmy. Na základě tohoto výpisu pak účetní popř. obchodní referent dané rezervace buď uvolňuje zpět do nabídky nebo je označuje jako zaplacené.
Zákazník také může hodnotit zájezdy a instruktory - činí tak vyplněním anketního lístku. Vše je pochopitelně anonymní.
Požadovanou funkčnost systému zachycuje model jednání.
Tento model zachycuje, kdo se systémem přijde přímo do styku (aktor = A_) a k čemu systém používá (typ jednání = U_). Názvy jsou samovysvětlující.
- A_zákazník
- U_informace_o_zájezdech
- A_obchodní_referent
- U_nový_zakazník
- U_změna_dat_u_zakazníka
- U_zrušení_zákazníka
- U_rezervace_místa
- U_zrušení_rezervace_místa
- U_zaplacení_místa
- A_účetní
- U_zrušení_rezervace_místa
- A_správa_zájezdů
- U_nový_instruktor
- U_změna_dat_u_instruktora
- U_zrušení_instruktora
- U_nový_zájezd
- U_změna_dat_u_zájezdu
- U_zrušení_zájezdu
- U_změna_dat_u_místa
- U_přidání_instruktora_k_zájezdu
- U_změna_aktivity_instruktora
- U_změna_aktivity_zájezdu
Tento oddíl se dělí na tři pododdíly:
Rád bych uvedl pár (důležtých) poznámek k analýze, designu a implementaci. Sice tím trochu předběhnu, ale:
Během vytváření systému jsem se dostal do zvláštní situace. Systém je projektován pomocí objektových metodik. V konečné fázi se také počítá s jeho objektovou implementací. Zatím však je však systém implementován v jazyce PHP. Tento jazyk sice umožňuje práci s objekty, ale bylo by dost odvážné nazývat ho objektovým programovacím jazykem. Právě i pro špatnou podporu objektů v PHP jsem se přidržel klasické strukturované implementace. Proč jsem však zvolil nevhodné implementační prostředí? Navíc samotná povaha úlohy - správa databáze (zápisy, změna, prohlížení) - si objektový způsob nijak nezasluhuje, ba co víc, nezdá se ani být příliš vhodný. To vybízí k další (závažnější) otázce: Proč jsem tedy vůbec úlohu řešil objektově?
Během řešení problému se systém rozpadl na tři části.
Pokud je logika aplikace vymýšlena objektově, u většiny problémů mi přijde myšlenka objektů (jakožto souhrn popisných dat a jejich chování) přirozenější než modulární procedurální programování. Ať tak či tak, samotná logika aplikace, pokud ji velmi zúžíme, je skutečně jen několik operací nad daty v relační databázi a tedy přístup data × procesy není vůbec špatný (důkazem budiž implementace v PHP). Pokud však přesto budeme analyzovat systém jako součinnost několika objektů, umožní nám to mnoho problémů značně zobecnit (vývoj podsysytémů třeba jako komponent pro další použtí), nehledě na možnosti moderních objektových jazyků (C++, Java) a moderních vývojových prostředí (VCL).
A právě subsystémy komnikace aktor - systém a spolupráce s relační databází byly zamýšleny jako komponenty. Při jejich analýze se objektové řešení přímo nabízelo (odvozené třídy, metatypy). Zájemci viz http://sorry.vse.cz/~xslom03/projekty/, odkazy na předměty it_357 (OOMT - analýza) a it_459 (OOMT - design).
Nyní již mohu odpovědět na výše položené otázky:
Závěrem budiž řečeno, že zmiňovanými komponentami se nadále nebudu zabývat. Toto rozhodnutí se projeví na obsahu dokumentu tak, že část "Analýza" bude objektová, část "Design" nebude popisovat komponenty a bude odrážet některé změny, které bylo nutné provést kvůli implementačnímu prostředí a část "Implementace" zcela podřídím současné implementaci v PHP. Zájemce o objektovou analýzu, design a implementaci komponent odkazuji na výše zmíněnou stránku.
Úloha není příliš složitá. Cestovní kancelář nabízí zájezdy s určitým počtem míst. Zákazník tato místa (resp. zájezdy) kupuje. Každý zájezd vede alespoň jeden instruktor. Zákazník může pochopitelně koupit více míst najednou.
Pro budoucí plánované rozšíření úlohy - viz část "4.2.1. - Vrstvy aplikace", se budou muset přidat nějaká data a přibudou nějaké asociace, avšak model jako takový by se neměl nijak radikálně měnit.
Model odpovědností používám k tomu, abych si udělal představu o funkčnosti tříd.
U modelu odpovědností předpokládám:
Následuje seznam odpovědností, přiřazený třídám aplikační logiky (C_).
Odpovědnost C_ třída Jaká místa si zákazník objednal
Na jaké zájezdy jezdil
Nová rezervaceC_zákazník Správa seznamu určitých zákazníků
Nový zákazník
Zrušení zákazníka
Vyhledání zákazníkaC_zákazníci Tvorba míst
Změna parametrů míst zájezdu
Jací instruktoři ho vedou
Zaktivnění / deaktivování zájezduC_zájezd Správa seznamu určitých zájezdů
Nový zájezd
Zrušení zájezd
Vyhledání zájezdu
Přidání instruktora k zájezduC_zájezdy Jaký zákazník si objednal toto místo
Zaplacení místa
Rezervování místaC_místo Jaké zájezdy vede C_instruktor Správa seznamu určitých instruktorů
Nový instruktor
Zrušení instruktora
Vyhledání instruktora
Zaktivnění / deaktivování instruktoraC_instruktoři
Věcná omezení stanoví požadavky na asociace takové, aby nedocházelo k logickým chybám.
Již jsem uvedl, že na program (v takovém stavu, v jakém je teď) měla velký vliv volba implementačního prostředí - objektová analýza a neobjektová implementace! Jaké důvody mě k tomu vedly jsem již zmínil v úvodu. Jakým způsobem to ovlivnilo design a implementaci se pokusím popsat nyní. Znovu připomínám, že program zamýšlím implementovat jednou objektově v C++, v prostředí X window OS systému Linux. Navíc dobrá tvorba komponenty zajišťující komunikaci aktor - systém může značně zjednodušit komunikaci se systémem - třeba tak, že bude produkovat výstup ve formátu XML - a tak zajistit skutečnou nezávislost na platformě.
V konečné verzi by aplikace měla být realizována aplikačním serverem, jež bude odpovědný za centrální správu dat pro více konkurujících si klientských aplikací. Data bude podle potřeby načítat či zapisovat do (relační) db. Aplikační server bude také poskytovat mnohem více funkcí:
Zatím systém vypadá takto:
vrstvy: SQL databáze <----> PHP skripty <----> HTML stránky umístění: db server <----> www server <----> www klient
Rozhodl jsem se, že s klientem bude komunikace probíhat přes www prohlížeč. Tento způsob komunikace vyžaduje jisté speciální zásahy do programu. Je to dáno nespojovanou spolupráci www klienta a www serveru. Po vznesení požadavku na server je zpuštěn jeden řetěz procesů (thread), ten je obsloužen a výsledek je zaslán zpět klientovi. Pomineme-li to, že to nutí tvůrce aplikací pro každý požadavek udržovat stavové informace stále znovu (ve skriptech toho dosahuji často elementem INPUT type="HIDDEN"
a předáváním parametrů metodou GET), je celý systém vlastně soustavou malých prográmů, zajišťujícíh jednu jedinou věc.
Během analýzy jsem příliš neřešil, jak přesně tato komunikace bude probíhat. Je jasném že se musí řešit tyto problémy - každý aktor má (1) různá oprávnění nad daty, (2) zajímají ho odlišné části dat, (3) přeje si nad nimi provádět odlišné funkce. Proto má každý aktor systému své vlastní stránky. Ty zobrazují to, co si přeje vidět a umožňují mu provádět jen ty operace, které smí nad daty provádět.
Interakční rozhraní (komunikace s aktorem) + transakční mng (aplikační logika).
Aktor bude komunikovat se systémem zatím přes www prohlížeč. Tato komunikace má své výhody, ale i nevýhody. Mezi základní výhody patří snadnost obsluhy programu uživatelem. Mezi základní nevýhody složité uchovávání stavových informací (HIDDEN položky HTML formuláře, cookies, spojení na db server).
Aplikační logika je zcela logicky realizována transakčním manažerem. Bohužel db server MySQL podporuje transakční zpracování až v případě, že se mu to přímo řekne, což může pouze jeho správce - nejsem si jist, jak to na serveru sorry chodí, takže transakce neužívám (pochopitelně zajišťuji možnost provádění několika atomických operací nad db v jednom logickém celku najednou jinak) - výsledkem je jediná nevýhoda - při neočekávaném pádu systému, hrozí nebezpečí vzniku nekonzistence dat. Viz níže.
Obecně lze říci, že program se sestává z jednotné datové základny, nad kterou operuje více konkurujících si aplikací. V objektovém designu rozlišuji tři podsystémy (aplikční logika, 2 komponenty), při realizaci pomocí PHP o klasických podsystémech není moc co říci. Presentaci obstará www prohlížeč, položení dotazu db serveru a tvorbu odpovědi (HTML stránky) PHP skript.
Práce s daty je zde klíčovým problémem. K uložení a organizaci dat používám relační databázi MySQL na systému OS Linux. Nevýhodou v datové úloze může být ignorance transakčního zpracování v MySQL, ale tato databáze poskytuje i jiné mechanismy, jak zajistit konzistenci dat. Věcná omezení kontroluji na úrovni aplikační logiky (PHP skript) a na základě této kontroly zajistím bezpečný průběh atomických operací v db (zamknutí příslušných tabulek, zápis do logsouborů). Musím ale dodat, že k využití originálních logsouborů db MySQL bych potřeboval mít práva správce db serveru - ty pochopitelně nemám. Mohl bych si sice vytvářet vlastní logsoubory, ale nepovažuji to za účelné - ve skutečnosti bych totiž při normálním provozu tato práva měl.
MySQL a transakce. Tvůrci MySQL je neimplementovali do prvních verzí MySQL zcela záměrně - kvůli rychlosti prováděných operací. Neexistenci transakcí obcházeli udělováním výhradních práv na čtení a modifikaci tabulky. Nyní již lze transakce užívat, ale musí se to přímo nastavit. Neznám přesnou konfiguraci MySQL serveru na počítači sorry a raději nic neriskuji a užívám to, co bude fungovat určitě - atomické operace s tím, že konzistenci zajistí (při běhu aplikace) správné zámky na tabulky, v případě pádu pak skutečně dobře vedené logsoubory a zálohy, kterými lze uvést db do konzistentního stavu velmi rychle.
Jedná se o homogenní systém (centrálně uložená databáze, přistupuje k ní více klientů).
Různí aktoři operují s různými daty a spouští nad nimi jiné operace. Každý komunikuje tedy s db po svém. Vyjímkou je aktor A_účetní, jež užívá systém k jediné funkci - Mazání nezaplacených rezervací. pro tohoto aktora a jeho jediný typ jednání jsem nechtěl vytvářet zvláštní aplikaci. Proto používá komunikaci se systémem stejnou, jako A_obchodní_referent, s tím, že používá pouze jeho jednu funkci.
Vnější řízení - paralelní (díky Unixu a MySQL). Vnitřní řízení - procedurální.
Z povahy Unixu běží jednotlivé aplikace zcela nezávisle na sobě. Díky způsobu, jakým MySQL obhospodařuje jednotlivé žádosti o službu (v terminologii MySQL = threads = řetězce procesů), lze zajistit bezproblémový běh více aplikací zamykáním příslušných tabulek (viz implementace).
Cílem je imlplementovat aplikaci, tak jak je zde popsána. Pro každého aktora budu vytvářet vlastní aplikaci (vlastní PHP skripty), zřejmě v tomto pořadí:
Testy provedu na cvičné db o několika málo záznamech. Pouze ověřím logickou funkčnost systému, nebudu řešit jeho skutečné zatížení.
Tato část bude zcela podřízena současné implementaci v neobjektovém prostředí PHP.
Jsou pochopitelně jen vyznačeny vazby mezi tabulkami, které jsou v db. Pokud chci např. zjist, na jaké zájezdy jezdí zákazník, lze to učinit vhodným SQL dotazem (viz níže, popř. zdrojový kód).
Atributy entit popíši nejlépe db skriptem pro tvorbu tabulek.
CREATE TABLE ins ( id INT NOT NULL, jmeno VARCHAR(20) DEFAULT '<jmeno>', prijmeni VARCHAR(20) DEFAULT '<prijmeni>' NOT NULL, aktivni ENUM ('ano', 'ne') DEFAULT 'ano' NOT NULL, pocet_hodnoceni INT DEFAULT '0' NOT NULL, hodnoceni INT DEFAULT '0' NOT NULL, rc CHAR(11) DEFAULT '<rod_cislo>' NOT NULL, PRIMARY KEY(id) ); CREATE TABLE mis ( id INT NOT NULL, cena DOUBLE(8, 2) DEFAULT '0.00' NOT NULL, rezervace DATE DEFAULT NULL, zaplaceno DATE DEFAULT NULL, zaj_id INT NOT NULL, zak_id INT DEFAULT NULL, PRIMARY KEY(id) ); CREATE TABLE zaj ( id INT NOT NULL, nazev VARCHAR(30) DEFAULT '<nazev>' NOT NULL, zacatek DATE DEFAULT '0000-00-00' NOT NULL, konec DATE DEFAULT '0000-00-00' NOT NULL, aktivni ENUM ('ano', 'ne') DEFAULT 'ano' NOT NULL, pocet_hodnoceni INT DEFAULT '0' NOT NULL, hodnoceni INT DEFAULT '0' NOT NULL, url VARCHAR(40) DEFAULT '<http://>' NOT NULL, PRIMARY KEY(id) ); CREATE TABLE zak ( id INT NOT NULL, jmeno VARCHAR(20) DEFAULT '<jmeno>' NOT NULL, prijmeni VARCHAR(20) DEFAULT '<prijmeni>' NOT NULL, mesto VARCHAR(30) DEFAULT '<mesto>' NOT NULL, ulice VARCHAR(30) DEFAULT '<ulice>' NOT NULL, psc CHAR(5) DEFAULT '<psc>' NOT NULL, rc CHAR(11) DEFAULT '<rod_cislo>' NOT NULL, PRIMARY KEY(id) ); CREATE TABLE asoc_ins_x_zaj ( ins_id INT NOT NULL, zaj_id INT NOT NULL, PRIMARY KEY(ins_id, zaj_id) );
V tomto bodě popíši dynamiku systému pouze z pohledu probíhajících činností. K tomuto popisu mi poslouží slovní scénáře typů jednání (U_), odvozených v modelu jednání. Každý typ jednání lze chápat jako činnost (jako souhrn procesů, které jsou nutné k tomu, aby tato činnost byla uspokojivě vyřešena). Popisují akce uživatele a reakci systému.
Používám toto značení:
A: Akce aktora (zmáčknutí tlačítka, následdování odkazu) S: Akce systému (provedení skriptu - pokud je složitější, je to rozfázováno) ?: Dotaz systému (očekávání akce od aktora, potvrzení akce aj.)
Vesměs lze říci, že veškeré typy jednání vlastně zajišťují prostou manipulaci s daty prostřednictvím prohlížeče. Po té co uživatel zvolí jistou operaci, je vygenerována HTML stránka, jsou do ní popř. načteny data z db. Uživatel provede, co chtěl, a odešle stránku zpět www serveru. Pokud je to potřeba je provedena kontrola dat, je vyžádáno potvrzení akce. Následně jsou změny promítnuty do db anebo jsou zrušeny. Většinou to končí návratem na úvodní stránku.
Poznámka: U dalších typů jednání předpokládám, že uživatel má spuštěnu aplikaci - tj. má zobrazenu úvodní stránku, odkud vyvolal příslušnou operaci (tlačítkem, odkazem). Navíc, protože u většiny typů jednání končí činnost vypsáním hlášení o úspěchu / neúspěchu akce a návratu na úvodní stránku, po té, co uživatel zprávu vezme na vědomí, mnohdy to ani neuvádím.
Viz výše.
Probíhá obdobně, jako U_nový_zákazník (tzn. kontrola dat, zápis do db).
Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db).
Probíhá obdobně, jako U_zrušení_zákazníka, s tím rozdílem, že jsou zrušeny i veškeré informace o tom, které zájezdy vedl.
Probíhá obdobně, jako U_nový_zákazník (tzn. kontrola dat, zápis do db).
Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db).
Probíhá obdobně, jako U_zrušení_zákazníka, s tím rozdílem, že:
Probíhá obdobně, jako U_změna_dat_u_zákazníka (tzn. načtení dat, kontrola nových dat, zápis do db). Avšak je tu jeden rozdíl. Změna dat u jednoho místa v zájezdu se aplikuje na všechna místa v zájezdu, která ještě nejsou rezervovaná.
Probíhá v rámci U_změna_dat_u_instruktora (zájezd je vyřazen z nabídky).
Probíhá v rámci U_změna_dat_u_instruktora (instruktor se od této chvíle považuje za propuštěného).
Tato část nemusí být nijak rozsáhlá, protože se systémem uživatel komunikuje prostřednictvím internetového prohlížeče. Veškeré ovládání je tudíž grafické (pomocí standardních grafických prvků) a předpokládám, že uživateli známé; pokud tomu tak není odkazuji zájemce na nápovědu prohlížeče. Předpokládám tudíž, že uživatel ví, co to je odkaz, formulář apod..
Musím zde podoknout, že chování programu (oficiální distribuce) bude trošku odlišné. Důvody, proč tomu tak je, vysvětluji v části "Implementace". Obecně mohu na tomto místě říci, že bych k ideálnímu provozování programu potřeboval oprávnění, která nemám (administrace unixového systému, administrace databáze MySQL).
Program spustíte tak, že do spuštěného prohlížeče zadáte adresu, kterou Vám sdělí správce systému. Prosím, uvědomte si, že podle toho, jakým způsobem se systémem pracujete, podle toho se liší adresa. Pro testování prototypu je ale adresa stejná pro všechny uživatele systému: http://sorry.vse.cz/~xslom03/bak_it/src/uvod.html.
Po zadání adresy Vás uvítá hlavní obrazovka. Doporučuji, abyste si tuto stránku zavedli do svých oblíbených položek - kdykoli se v systému "ztratíte", můžete se bez problémů dostat zpět. Úvodní stránka se nijak neliší od jiných internetových stránek. Klikáním na odkazy, vyplňováním jednoduchých formulářů plníte svoji každodenní práci.
Možná budete muset dodržovat určitá nastavení ve Vašem prohlížeči (sdělí Vám správce), prosím dodržujte tato nařízení. Zajistíte tím bezproblémový běh aplikace.
Není vyloučeno, že systém bude požadovat vaši identifikaci (zadání uživatelského jména a hesla) - opět Vám vše potřebné sdělí správce. Prototyp žádné identifikační procedury nevyžaduje. Hlavní stránky jednotlivých uživatelů jsou veřejně dostupné z výše uvedené stránky.
Informační systém by měl plnit určité funkce. Tyto funkce se liší podle toho, jaký uživatel se systémem pracuje. Pakliže se umíte pohybovat v prohlížeči, umíte spouštět i jednotlivé funkce systému. Jaké funkce můžete provádět? Podívejte se prosím na model jednání v části "Zadání". Slovem aktor, je označován určitý druh uživatele (snadno z názvu poznáte, jakým aktorem jste) a souslovím typ jednání jsou označeny Vaše možné akce se systémem. Anebo si spusťte Vaši hlavní stránku.
Ačkoli je práce se systémem velmi snadná, je dobré dodržovat určité zásady:
Program nemusíte nijak ukončovat - skončí vlastně tak, že dokončí nahrávání právě aktuální stránky. Jinými slovy, ukončíte ho stejně jako ukončujete prohlížení internetových stránek - zavřete prohlížeč.